home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1535 < prev    next >
Text File  |  1995-07-25  |  10KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          E. Gavron
  8. Request for Comments: 1535                            ACES Research Inc.
  9. Category: Informational                                     October 1993
  10.  
  11.  
  12.               A Security Problem and Proposed Correction
  13.                    With Widely Deployed DNS Software
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard.  Distribution of this memo is
  19.    unlimited.
  20.  
  21. Abstract
  22.  
  23.    This document discusses a flaw in some of the currently distributed
  24.    name resolver clients.  The flaw exposes a security weakness related
  25.    to the search heuristic invoked by these same resolvers when users
  26.    provide a partial domain name, and which is easy to exploit (although
  27.    not by the masses).  This document points out the flaw, a case in
  28.    point, and a solution.
  29.  
  30. Background
  31.  
  32.    Current Domain Name Server clients are designed to ease the burden of
  33.    remembering IP dotted quad addresses.  As such they translate human-
  34.    readable names into addresses and other resource records.  Part of
  35.    the translation process includes understanding and dealing with
  36.    hostnames that are not fully qualified domain names (FQDNs).
  37.  
  38.    An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
  39.    domain name is of the format {name}
  40.  
  41.    A domain name may have many parts and typically these include the
  42.    host, domain, and type.  Example:  foobar.company.com or
  43.    fooschool.university.edu.
  44.  
  45. Flaw
  46.  
  47.    The problem with most widely distributed resolvers based on the BSD
  48.    BIND resolver is that they attempt to resolve a partial name by
  49.    processing a search list of partial domains to be added to portions
  50.    of the specified host name until a DNS record is found.  This
  51.    "feature" is disabled by default in the official BIND 4.9.2 release.
  52.  
  53.    Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
  54.                              to    UnivHost.University.EDU
  55.  
  56.  
  57.  
  58. Gavron                                                          [Page 1]
  59.  
  60. RFC 1535               DNS Software Enhancements            October 1993
  61.  
  62.  
  63.    The resolver client will realize that since "UnivHost.University.EDU"
  64.    does not end with a ".", it is not an absolute "rooted" FQDN.  It
  65.    will then try the following combinations until a resource record is
  66.    found:
  67.  
  68.                 UnivHost.University.EDU.Tech.ACES.COM.
  69.                 UnivHost.University.EDU.ACES.COM.
  70.                 UnivHost.University.EDU.COM.
  71.                 UnivHost.University.EDU.
  72.  
  73. Security Issue
  74.  
  75.    After registering the EDU.COM domain, it was discovered that an
  76.    unliberal application of one wildcard CNAME record would cause *all*
  77.    connects from any .COM site to any .EDU site to terminate at one
  78.    target machine in the private edu.com sub-domain.
  79.  
  80.    Further, discussion reveals that specific hostnames registered in
  81.    this private subdomain, or any similarly named subdomain may be used
  82.    to spoof a host.
  83.  
  84.         Example:        harvard.edu.com.        CNAME   targethost
  85.  
  86.    Thus all connects to Harvard.edu from all .com sites would end up at
  87.    targthost, a machine which could provide a Harvard.edu login banner.
  88.  
  89.    This is clearly unacceptable.  Further, it could only be made worse
  90.    with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
  91.  
  92. Public vs. Local Name Space Administration
  93.  
  94.    The specification of the Domain Name System and the software that
  95.    implements it provides an undifferentiated hierarchy which permits
  96.    delegation of administration for subordinate portions of the name
  97.    space.  Actual administration of the name space is divided between
  98.    "public" and "local" portions.  Public administration pertains to all
  99.    top-level domains, such as .COM and .EDU.  For some domains, it also
  100.    pertains to some number of sub-domain levels.  The multi-level nature
  101.    of the public administration is most evident for top-level domains
  102.    for countries.  For example in the Fully Qualified Domain Name,
  103.    dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
  104.    of public administration.  Only the left-most portion is subject to
  105.    local administration.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Gavron                                                          [Page 2]
  115.  
  116. RFC 1535               DNS Software Enhancements            October 1993
  117.  
  118.  
  119.    The danger of the heuristic search common in current practise is that
  120.    it it is possible to "intercept" the search by matching against an
  121.    unintended value while walking up the search list.  While this is
  122.    potentially dangerous at any level, it is entirely unacceptable when
  123.    the error impacts users outside of a local administration.
  124.  
  125.    When attempting to resolve a partial domain name, DNS resolvers use
  126.    the Domain Name of the searching host for deriving the search list.
  127.    Existing DNS resolvers do not distinguish the portion of that name
  128.    which is in the locally administered scope from the part that is
  129.    publically administered.
  130.  
  131. Solution(s)
  132.  
  133.    At a minimum, DNS resolvers must honor the BOUNDARY between local and
  134.    public administration, by limiting any search lists to locally-
  135.    administered portions of the Domain Name space.  This requires a
  136.    parameter which shows the scope of the name space controlled by the
  137.    local administrator.
  138.  
  139.    This would permit progressive searches from the most qualified to
  140.    less qualified up through the locally controlled domain, but not
  141.    beyond.
  142.  
  143.    For example, if the local user were trying to reach:
  144.  
  145.         User@chief.admin.DESERTU.EDU from
  146.         starburst,astro.DESERTU.EDU,
  147.  
  148.    it is reasonable to permit the user to enter just chief.admin, and
  149.    for the search to cover:
  150.  
  151.         chief.admin.astro.DESERTU.EDU
  152.         chief.admin.DESERTU.EDU
  153.  
  154.    but not
  155.  
  156.         chief.admin.EDU
  157.  
  158.    In this case, the value of "search" should be set to "DESERTU.EDU"
  159.    because that's the scope of the name space controlled by the local
  160.    DNS administrator.
  161.  
  162.    This is more than a mere optimization hack.  The local administrator
  163.    has control over the assignment of names within the locally
  164.    administered domain, so the administrator can make sure that
  165.    abbreviations result in the right thing.  Outside of the local
  166.    control, users are necessarily at risk.
  167.  
  168.  
  169.  
  170. Gavron                                                          [Page 3]
  171.  
  172. RFC 1535               DNS Software Enhancements            October 1993
  173.  
  174.  
  175.    A more stringent mechanism is implemented in BIND 4.9.2, to respond
  176.    to this problem:
  177.  
  178.    The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
  179.    to only try the first and the last of the examples shown.
  180.  
  181.    Any additional search alternatives must be configured into the
  182.    resolver EXPLICITLY.
  183.  
  184.    DNS Name resolver software SHOULD NOT use implicit search lists in
  185.    attempts to resolve partial names into absolute FQDNs other than the
  186.    hosts's immediate parent domain.
  187.  
  188.    Resolvers which continue to use implicit search lists MUST limit
  189.    their scope to locally administered sub-domains.
  190.  
  191.    DNS Name resolver software SHOULD NOT come pre-configured with
  192.    explicit search lists that perpetuate this problem.
  193.  
  194.    Further, in any event where a "." exists in a specified name it
  195.    should be assumed to be a fully qualified domain name (FQDN) and
  196.    SHOULD be tried as a rooted name first.
  197.  
  198.    Example:  Given  user@a.b.c.d connecting to e.f.g.h  only two tries
  199.              should be attempted as a result of using an implicit
  200.              search list:
  201.  
  202.                 e.f.g.h.  and e.f.g.h.b.c.d.
  203.  
  204.              Given user@a.b.c.d. connecting to host those same two
  205.              tries would appear as:
  206.  
  207.                 x.b.c.d.  and x.
  208.  
  209.    Some organizations make regular use of multi-part, partially
  210.    qualified Domain Names.  For example, host foo.loc1.org.city.state.us
  211.    might be used to making references to bar.loc2, or mumble.loc3, all
  212.    of which refer to whatever.locN.org.city.state.us
  213.  
  214.    The stringent implicit search rules for BIND 4.9.2 will now cause
  215.    these searches to fail.  To return the ability for them to succeed,
  216.    configuration of the client resolvers must be changed to include an
  217.    explicit search rule for org.city.state.us.  That is, it must contain
  218.    an explicit rule for any -- and each -- portion of the locally-
  219.    administered sub-domain that it wishes to have as part of the search
  220.    list.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Gavron                                                          [Page 4]
  227.  
  228. RFC 1535               DNS Software Enhancements            October 1993
  229.  
  230.  
  231. References
  232.  
  233.    [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
  234.        RFC 1034, USC/Information Sciences Institute, November 1987.
  235.  
  236.    [2] Mockapetris, P., "Domain Names Implementation and Specification",
  237.        STD 13, RFC 1035, USC/Information Sciences Institute, November
  238.        1987.
  239.  
  240.    [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
  241.        974, CSNET CIC BBN, January 1986.
  242.  
  243.    [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
  244.        "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
  245.        USC/Information Sciences Institute, USC, October 1993.
  246.  
  247.    [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
  248.        1537, CWI, October 1993.
  249.  
  250. Security Considerations
  251.  
  252.    This memo indicates vulnerabilities with all too-forgiving DNS
  253.    clients.  It points out a correction that would eliminate the future
  254.    potential of the problem.
  255.  
  256. Author's Address
  257.  
  258.    Ehud Gavron
  259.    ACES Research Inc.
  260.    PO Box 14546
  261.    Tucson, AZ 85711
  262.  
  263.    Phone: (602) 743-9841
  264.    EMail: gavron@aces.com
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Gavron                                                          [Page 5]
  283.  
  284.